Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9710/000011_owner-urn-ietf _Sat Oct 25 07:08:59 1997.msg

Internet Message Format | 1997-10-28 | 7KB

Received: (from daemon@localhost)
    by services.bunyip.com (8.8.5/8.8.5) id HAA13835
    for urn-ietf-out; Sat, 25 Oct 1997 07:08:59 -0400 (EDT)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
    by services.bunyip.com (8.8.5/8.8.5) with ESMTP id HAA13828
    for <[e-mail]>; Sat, 25 Oct 1997 07:08:56 -0400 (EDT)
Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65])
    by mocha.bunyip.com (8.8.5/8.8.5) with SMTP id HAA05495;
    Sat, 25 Oct 1997 07:08:52 -0400 (EDT)
Received: from elec.isei.jrc.it (elec.jrc.it) by mrelay.jrc.it (4.1/EB-950131-C)
    id AA22078; Sat, 25 Oct 97 13:09:23 +0100
Received: from elect6.jrc.it by elec.isei.jrc.it (4.1/EI-3.0m)
    id AA02905; Sat, 25 Oct 97 12:07:52 +0100
Posted-Date: Sat, 25 Oct 1997 13:08:42 +0100 (MET)
Date: Sat, 25 Oct 1997 13:08:42 +0100 (MET)
From: Dirk-Willem van Gulik <[e-mail]>
To: Dan Connolly <[e-mail]>
Cc: Leslie Daigle <[e-mail]>, [e-mail], [e-mail],
        [e-mail], [e-mail],
        [e-mail], [e-mail], [e-mail],
        [e-mail], [e-mail], [e-mail],
        [e-mail], [e-mail], [e-mail], [e-mail],
        [e-mail]
Subject: Re: [URN] Re: The UR* scheme registry, Citing URL/URI specs
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Reply-Path: [e-mail]
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
Reply-To: Dirk-Willem van Gulik <[e-mail]>
Errors-To: [e-mail]

On Fri, 24 Oct 1997, Dan Connolly wrote:

> Short version:
>
> Leslie Daigle wrote:
> > >      Syntax draft says "URIs are covered by other specs".
> > >      What other specs?
> >
> > RFC2141
>
> Hmmm.... checking...
> The term URI does not occur in RFC2141.
> So that's no help.
>

1630 ?!

Hmm, Alhoug I might sail into dangerous groups, I've always felt that
somewhere rough consensus suggest that in the big and happy
UR-<alphabet-soup> group of things a 'URI' could kind of be seen as the
thing that imposes constraints on all, i.e. RFC1630 (and I could see the
need for some updating there). The various URL specs (for http, finger,
ldap, z3950, handle-scheme, telnet, ftp, mailto, etc) should all just
refine the 1630 definition; as does the URN definition 2141.

Nicely enough, the 1994 written RFC 1630 says:

   URLs are listed here. The Uniform Resource Name (URN) debate attempts
   to define a name space (and presumably resolution protocols) for
   persistent object names. This area is not addressed by this document,
   which is written in order to document existing practice and provide a
   reference point for URL and URN discussions.

And I would most certainly advocate to use it as such a reference point,
and make the URN just one of those flavours URIs, and adhere to the
same 'Universal Syntax'.

Although I might be wrong, (and am most certainly wrong when it comes
to some of the URLs currently in use) I would assert that the current
URN (21441) syntax fits perfectly within the 1630 constraineds of its
'Universal Syntax'. If this is not the case we should fix it.

> > One specific document you don't seem to have been aware of is the URN syntax
> > standards-track RFC (RFC2141).
>
> I'm aware of it (I read some of the earlier drafts.) It specifies
> a syntax where all the strings start with urn: . I got
> the impression urn: would go in the list along with http:
> and ftp: and all the rest in places like the IANA registry,
> the Java APIs, the Address/Location field in browsers etc.

> Not so?

Syntax wise, I would guess that most people on this list would give a big
yes, sematically of course it is a diffeernt issue.

> > I won't speak directly to the issue of whether or not the W3C documents
> > should refer to URIs or URLs,

> I wish you would.

Well, let me make a stab at this as well... jus to see if this would
narrow down the discussion.

I personally believe that the w3c documets should use the term URI when
they refer to a universally applicable name which is to contain references
to registered protocols, namespaces. When the documents refers to the
location of the resource, as to be used to obtain the resource from the
given localtion(s) with the given protocol, i.e.without any level of
indirection outside the name (though possibly within the protocol) then
the more preciese term URL should be used. If however the application
described in the w3c document needs to be very explicit about
the location independent resource idenfification it would be bettter to
use the URN word.

Quite naturally there is a blurr between a URNs and URLs, in particular a
carefully choosen URL might fullfill most, if not all, _functional_
requirements of a URN; and a poorly chosen URN space can end up being as
messy and location dependent as URLs.

So as a usefull guideline, I would look at the functional requirements in
the w3c drafts, what is it that one expects from that information element
reffered to, and when in doubt use the 'URI' word. Though it would surpize
if that is that often needed, when you get to the gritty details of
actually coding it, meeting the functional requirements of URNs and using
them that way makes them very, very different from URL's and it is very
obvious which is which, and why you need both.

> > URLs.  URNs are discussed in RFC2141.  The syntaxes are intended to be
> > compatible.

> I keep hearing that, but I look at the standards-track documents,
> and I don't see it in black-and-white.

So would it help if there was an updated 1630 which talked only about URI
syntax, and and updated 2141 which only points to the URI syntax with a
refinement; and likewise for the URL definitions, etc. etc, I would still
like to keep 1630, as it gives a lot of 'architecture' information which
should not be lost.

i.e.
    urI Syntax     'scheme:path'
            escaping
    .urL = urI + meaning of the hash, ?, etc, relative stuff,
        protcol name registry
    ..HTTP = urL + naming segments, query string, etc
    ..FTP = urL + way to encode username passwd, etc, etc
    .urN = urI + naming schemes, etc.

as most is perceived to be defined this way anyway, the split up
over the defining documents is jsut a bit awkward.

Just my 200 lire's worth,

Dw.